The system and method described below relate, in general, to the interleaving of undelayed and intentionally delayed executable instructions, such as instructions described in the '681 application. The instructions may be contained within Messages that are communicated within and across systems for executing them, and use of the terms “instructions” and “Messages” may be used interchangeably below to refer to messages and the instructions they, contain. When the system contains multiple queues or buffers to, e.g., improve performance, it is important that the instructions are executed in a proper sequence.
The systems and methods described herein are applicable to any technical system utilizing undelayed and intentionally delayed executable instructions in conjunction with multiple buffers. One implementation of this technical system is in the field of automated trading, and although use in this field is described in detail below the technical application is not limited to this implementation, and the invention as a whole should be construed broadly and as a technical solution to a technical problem involving multiple buffers and sequencing of executable instructions.
In the past two decades, there has been extraordinary evolution in the automated handling of orders to buy and sell financial instruments including, but not limited to, equity securities, options, government debt securities, corporate debt securities, foreign exchange (currency), futures contracts, and options on futures contracts.
This evolution has typically resulted in manual trading being replaced by automated trading. However, by introducing automated trading into the field, new capabilities are provided that were simply not possible with manual trading. These capabilities include, but are not limited to, matching of buyers and sellers employing sophisticated order types and the use of fully automated Matching Systems to manage the execution priority of these orders, the limitations and restrictions of the terms of each order, and the actual matching of each buyer with each seller based on rules or algorithms which are particular to the regulatory framework in which the Matching System operator works and the rules of the Matching System operator.
As the matching of buyers and sellers became more automated, traditional Liquidity Providers (specialists, market makers, floor traders, OTC traders, etc.) have given way to automated Liquidity Providers who employ electronic systems to place orders to buy and sell securities. Collectively, today's markets rely largely on automated Liquidity Providers to be present to take the other side of a trade when a competitive buyer or seller enters the market.
Because of intense competition among trading venues, almost any financial instrument that is traded on an electronic Matching System is either traded in multiple trading venues and/or has a derivative relationship with another financial instrument that is electronically traded somewhere. For this reason, the pricing of almost any financial instrument will vary as the price of the same or a related financial instrument changes in some trading venue.
These interrelationships have led to a “speed war” which is fought among market participants. In some instances, a market participant is trying to be the first to recognize the change in the price of a financial instrument in one trading venue and execute a trade in the same financial instrument in another trading venue. In other instances, a market participant is trying to be the first to recognize the change in the price of a financial instrument in one trading venue and execute a trade in the same financial instrument or a related financial instrument in the same or a different trading venue.
These efforts—based on having a speed advantage in detecting and responding to changes in the price and size of quotations in a security—are part of a “latency arbitrage” strategy. Latency arbitrage can be described as the practice of exploiting disparities in the pricing of the same financial instrument or related financial instruments that are being traded in the same or different markets by taking advantage of the time it takes to access and respond to market information. For the purpose of this application, a “latency arbitrageur” is defined as a Liquidity Taker who employs a successful latency arbitrage strategy by shooting orders to Take Liquidity, from a contra party victim that has been unable to access and respond to the same market information fast enough to modify the price and/or size of the liquidity that the victim is providing.
One consequence of a successful latency arbitrage strategy is that the latency arbitrageur extracts an economic rent from the Liquidity Provider who, although highly automated, does not respond to the same changes in market information as quickly as the latency arbitrageur.
To avoid paying this economic rent to the latency arbitrageur, some Liquidity Providers respond by attempting to beat the latency arbitrageur in the “speed war.” However, this can be very costly, and even after committing significant resources to be faster, the Liquidity Provider may not succeed or may succeed for only a period of time after which the latency arbitrageur invests further and becomes faster yet again.
Other responses of the victim Liquidity Provider can range from providing liquidity at less competitive prices, providing less size at the same price, or—in the extreme—ceasing to act as a Liquidity Provider in an attacked financial instrument altogether. The impact of any of these responses is an undesirable reduction of liquidity in the marketplace.
Liquidity Providers are increasingly finding themselves under such latency arbitrageur attacks. The cost of doing nothing requires the Liquidity Provider to do something. The net impact of the range of responses taken has been an overall reduction in liquidity.
The “speed war” has resulted in various changes which seek to deemphasize the importance of speed in getting a Message containing one or more executable instructions to a Trading Center. Some of these changes involve Trading Centers which intentionally delay execution of Messages containing certain instructions based on a set of Delay Criteria. When intentionally delays are imposed, the length of the delay can be fixed (potentially based on the Delay Criteria which are met), randomized (within a range of delay times potentially based on the Delay Criteria which are met) or a combination of both fixed and randomized delay periods.
Intentional delays, as described herein, require an automated system and method for implementation because the length of an intentional delay is always less than one second and typically less than one millisecond—a period so short that the message handling can only be implemented by an automated system.